home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 9614 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.4 KB

  1. Path: mail2news.demon.co.uk!genesis.demon.co.uk
  2. From: Lawrence Kirby <fred@genesis.demon.co.uk>
  3. Newsgroups: comp.lang.c
  4. Subject: Re: malloc question
  5. Date: Tue, 12 Mar 96 00:04:40 GMT
  6. Organization: none
  7. Message-ID: <826589080snz@genesis.demon.co.uk>
  8. References: <4htonk$350@news.hklink.net> <4huctt$arv@sparcserver.lrz-muenchen.de> <314318AF.30F@iperbole.bologna.it> <4hvaj4$laj@solutions.solon.com> <AD69AACE9668D78B0@mcdiala09.it.luc.edu>
  9. Reply-To: fred@genesis.demon.co.uk
  10. X-NNTP-Posting-Host: genesis.demon.co.uk
  11. X-Newsreader: Demon Internet Simple News v1.27
  12. X-Mail2News-Path: genesis.demon.co.uk
  13.  
  14. In article <AD69AACE9668D78B0@mcdiala09.it.luc.edu>
  15.            VArase@varase.it.luc.edu "Verne Arase" writes:
  16.  
  17. >In article <4hvaj4$laj@solutions.solon.com>,
  18. >seebs@solutions.solon.com (Peter Seebach) wrote:
  19. >
  20. > >>Error?!? Why do you think that casting is an error? The standard ANSI
  21. > >>runtime library says:
  22. > >
  23. > >He didn't say it was an error, he said it could *hide* an error.
  24. >
  25. >Well, in the general case it _could_ hide an error.
  26. >
  27. >In this specific case, however, it _never_ hides an error. If malloc is
  28. >used in its standard context, we are simply coercing a slab of memory
  29. >aligned to the most stringent boundaries into a pointer of the desired
  30. >type.
  31.  
  32. It would hide an error if malloc was not previously declared (e.g. by
  33. including stdlib.h). Undeclared functions default to returning int so
  34. calling malloc like this results in undefined behaviour. Since it was not
  35. specific whether stdlib was included or not this is certainly a case where
  36. an error could be hidden.
  37.  
  38. >Provided the associated header is included
  39.  
  40. That's just it, you should never assume what isn't stated. This has been
  41. the cause of a problem too many times to ignore.
  42.  
  43. >***** flame on ******
  44. >This is one reason I stopped participating in C conferences; there's always
  45. >some language lawyer who'll tell a novice that a cast is an evil (even if
  46. >it has to do with casting a char * to an unsigned char * for use in a file
  47. >name).
  48.  
  49. Casts are not evil but they are dangerous and can be (and are) grossly
  50. misused especially by novices.
  51.  
  52. >What they normally fail to tell you is that any code much beyond the
  53. >sophistication of "Hello World" practically requires casts to produce
  54. >workable code.
  55.  
  56. They don't say this because it is simply isn't true, at least not with
  57. ANSI C. Casts are useful but you can write sophisticated code without using
  58. them. It takes experience to know which casts are safe and which are not.
  59. A beginner can easily get away without using them (particularly pointer
  60. casts) and will usually end up with better code when they do so.
  61.  
  62. >IMO, making a char a signed quantity
  63.  
  64. Whether char is signed or unsigned is implementation defined.
  65.  
  66. >(along with the infamous misplacement
  67. >of the boolean and operator's priority) have made more C programmer's lives
  68. >miserable than any other construct in any other language (that I've
  69. >encountered).
  70.  
  71. >Sure there are constructs that'll get you in trouble. But let us not forget
  72. >that C is the original "gun, bullet, foot" language, and requires care in
  73. >its use and execution.
  74.  
  75. Which means that as a beginner you should avoid the more dangrous features
  76. of the language until you have a better understanding of it and the issues
  77. involved.
  78.  
  79. -- 
  80. -----------------------------------------
  81. Lawrence Kirby | fred@genesis.demon.co.uk
  82. Wilts, England | 70734.126@compuserve.com
  83. -----------------------------------------
  84.